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Project  Summary 


In  this  project  we  aim  to  build  a  computational  framework  for  visualization  of  geometric 
objects  as  they  are  manipulated.  Specifically  we  have  built  an  environment  that  enables 
the  user  to  design  and  test  geometric  algorithms  by  visualizing  the  state  of  an  algorithm 
and  monitoring  the  objects  being  manipulated.  The  system  is  dubbed  GEOMAMOS  for 
GEometric  Object  MAnipulation/MOnitoring  System.  It  is  an  X-window  based,  menu- 
driven  system  and  runs  under  unix  operating  system.  A  World  Wide  Web  page  for  this 
project  can  be  found  at  http://www.ece.nwu.edu/~theory/geomamos.html. 


Project  Description 


Since  the  inception  of  this  project  four  years  ago,  we  have  successfully  built  a  working 
prototype  that  allows  the  user  to  manipulate  input  geometric  objects  with  a  mouse,  and  to 
visualize  the  contents  of  geometric  objects  in  the  user’s  program  with  a  simple  Graphic  read 
and  Graphic  write  statements.  We  have  developed  an  interprocess  communication  package 
utilizing  socket  based  UDP/TCP  protocol  for  message  passing  between  the  visualization 
process  and  the  user’s  program.  Geometric  object  classes  and  visualization  member  functions 
for  a  limited  class  of  objects  have  also  been  developed. 

Figure  1  shows  an  overall  block  diagram  of  the  system  GEOMAMOS.  Due  to  lack  of 
manpower,  components  GeoDDE,  GeoAnimator,  and  GeoAnalyzer  were  not  implemented. 
All  other  modules  have  been  implemented.  Let  us  explain  each  module  briefly. 

1.  GeoMAMOS  Panel  -  Main  control  panel. 

This  is  a  main  user  interface  of  the  system.  Prom  the  GeoPanel  one  can  launch  one 
or  more  GeoSheet  processes,  and  an  algorithm  browser.  It  is  a  centralized  control 
manager  responsible  for  the  management  of  all  available  GeoSheets  and  programs  in 
execution.  Any  GeoSheet  or  program  started  from  a  GeoPanel  will  first  be  connected 
to  the  GeoPanel.  GeoPanel  will  maintain  the  information,  such  as  the  host  machine 
IP  address  and  the  process  ID,  of  the  GeoSheet  or  program.  See  Figure  2. 

2.  GeoSheet  -  Visualization  subsystem. 

This  is  a  primary  component  of  GeoMAMOS,  which  is  responsible  for  graphic  input  and 
output.  It  is  an  interactive  visualization  tool  designed  to  simplify  geometric  algorithms 
visualization  procedures  in  a  distributed  environment.  It  is  display  device  independent, 
although  in  the  current  release  the  display  is  based  on  Xfig  (Facility  for  Interactive 
Generation  of  Figures  under  XI 1)^  and  is  primarily  for  2-dimensional  objects  and  runs 
under  the  Sun  Microsystems’  environment.  It  has  also  been  ported  to  other  platforms 
such  as  Silicon  Graphics  IRIS  workstations  to  support  3D  graphics,  called  GeoSDSheet. 

The  following  is  a  brief  summary  of  the  main  features  of  GeoSheet  that  supports  geo¬ 
metric  algorithm  visualization  and  development. 

•  On-Line  Visualization  Invocation.  This  allows  visualization  operations  to  be  ex¬ 
ecuted  directly  from  user’s  program.  We  enhance  Xfig  with  a  message  driven  in¬ 
terface  to  support  such  a  feature.  Compared  to  other  data  visualization  schemes, 
this  scheme  is  more  tightly  coupled  with  program  control  flow  and  provides  more 
flexible  visualization  support  at  source  code  level. 

•  Interactive  Graphical  Object  Drawing/Manipulation  Capability.  This  feature  is 
primarily  supported  by  Xfig  that  allows  the  user  to  draw  and  manipulate  objects 
interactively  in  an  X  window.  The  user  can  conveniently  use  a  mouse  to  create, 

^Smith,  B.  V.,  The  Xfig  User  Manual,  1993. 
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Figure  1:  Components  of  GeoMAMOS 
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Figure  2:  geoPanel  window  and  interaction  with  other  components. 


import  or  edit  data  objects  and  export  the  drawn  objects  to  other  GeoSheets,  or 
print  out  visualized  computation  results.  The  ability  of  importing  or  exporting 
visualized  objects  in  Xfig  or  postscript  format  is  also  useful  for  presenting  the 
computation  results. 

•  Communication/Comparisons  of  Algorithms.  GeoSheet  is  also  designed  to  serve 
as  a  communication  platform  for  different  algorithms  at  the  program  input  or 
output  level.  For  example,  an  algorithrri  pipeline  can  be  formed  by  directing 
the  output  of  one  algorithm  to  be  the  input  of  another  algorithm.  Algorithm 
pipeline  can  help  the  user  use  available  algorithms  to  explore  solutions  to  new 
problems.  Another  usage  of  GeoSheet  is  for  comparison  of  different  heuristics  for 
NP-complete  problems,  e.g.,  Steiner  tree  problem.  We  can  direct  all  outputs  of 
the  tested  heuristics  to  the  same  GeoSheet  and  use  different  colors  or  drawing 
attributes  to  represent  these  outputs.  Visually  we  can  compare  the  quality  of  the 
output. 

•  Distributed  GeoSheet  Manipulation.  Via  Internet  service  application  software  can 
be  exchanged  through  anonymous  ftp  services.  If  we  know  that  certain  programs 
are  available  at  remote  sites,  we  can  download  and  execute  them  locally.  How¬ 
ever  such  scheme  sometimes  requires  tedious  installation  efforts  and  large  storage 
space.  Thus  multiple  copies  of  the  same  software  exist.  This  is  not  only  ineffi¬ 
cient  in  resource  usage,  but  also  inconvenient,  if  we  only  need  to  test  run  a  small 
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Figure  3:  An  internal  block  architechture  of  GeoSheet. 


program.  It  is  worse  if  the  needed  programs  are  available  at  different  sites.  This 
shortcoming  can  be  removed  if  we  allow  the  user  to  run  those  algorithms  directly 
at  remote  sites  and  display  the  results  locally.  GeoSheet  is  equipped  with  remote 
execution  facilities  to  assist  the  user  to  execute  algorithms  at  distributed  sites. 
There  is  a  limitation,  of  course.  Since  the  communication  among  different  sites 
is  done  via  message  passing,  reliability  of  the  communication  link  is  crucial.  We 
have  successfully  tested  this  facility  in  our  local  network  but  when  the  amount  of 
data  to  be  transmitted  over  the  Internet,  some  packets  may  get  lost. 

GeoSheet  can  also  be  launched  on  its  own  without  using  the  geoPanel,  and  with  GeoIPC 
it  can  be  executed  as  a  separate  process  across  the  network.  See  Figures  3  and  4  for 
an  illustration  of  its  architecture  and  Ref.  [21]  for  more  details. 

3.  GeoGDB  -  A  front-end  X-windows  based  graphical  debugger. 

The  graphical  debugger  runs  on  top  of  the  UNIX  source-level  debugger,  gdb.  It  has 
a  friendly  multi-window  graphical  user  interface  that  serves  as  the  primary  commu¬ 
nication  bridge  between  the  user’s  program  and  the  underlying  debugger.  The  user 
can  open  one  or  more  watch  windows  to  observe  the  contents  of  different  data  ob¬ 
jects  as  the  program  is  being  executed.  The  component  is  to  be  augmented  with  a 
command  recorder  which  will  allow  the  user  to  plan/edit  an  animation  sequence  while 
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Figure  4:  GeoSheet  can  be  run  as  a  separate  process  in  distributed  networks. 


stepping  through  the  code  during  the  debugging  phase.  The  sequence  can  be  stored 
in  a  profile  to  be  re-animated  for  illustration/demonstration  purposes.  This  is  to  be 
interfaced  with  the  component  GeoAnimator.  See  Figure  5  for  an  illustration  of  the 
architecture  of  GeoGDB. 

4.  GeoIPC  -  Interprocess  communication 

This  component  is  the  backbone  of  the  distributed  nature  of  the  system.  It  is  im¬ 
plemented  using  sockets  based  on  UDP/TCP  and  serves  as  a  communication  vehicle 
among  all  processes,  including  GeoSheet,  user’s  program,  GeoPanel,  GeoGDB,  GeoAn¬ 
imator  and  GeoAnalyzer.  GeoIPC  supports  the  connection  establishment,  communica¬ 
tion  and  synchronization  among  various  components.  Its  functions  include  connecting 
distributed  GeoSheets  and  algorithm  executions;  locating  the  GeoSheet  specified  in 
the  QuerySheet  operation;  and  providing  the  message  communication  utility  that  sup¬ 
ports  virtual  buffer  of  logically  unlimited  length,  and  the  process  synchronization  and 
communication  for  programs  and  GeoSheet. 

5.  GeoLIB  -  A  library  of  geometric/graph  objects. 

Like  most  of  the  User  Interface  objects,  the  geometric/graph  objects  of  GeoLIB  are 
maintained  in  a  class  hierarchy.  Such  a  feature  helps  the  user  quickly  locate  the  ap- 
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Figure  5:  The  architecture  of  GeoGDB 


propriate  objects  they  would  like  to  use  in  their  design.  A  complex  object  can  be 
composed  of  several  simple  sub-components  which  are  provided  by  the  GeoLIB.  Ge- 
oLIB  is  designed  to  support  as  many  geometric/graph  objects  as  possible;  the  initial 
set  of  supported  objects  contains  only  the  basic  and  the  most  frequently  used  graph 
objects.  When  a  new  data  structure  for  a  particular  geometric/graph  object  is  intro¬ 
duced  in  the  algorithm  development  process,  GeoLIB,  with  the  aid  of  GeoDDE,  can  be 
easily  extended  to  support  the  new  object  by  adding  the  class  definition  and  related 
routines. 

6.  GeoDDE  -  A  data  structure  diagram  editor. 

GeoDDE  is  not  yet  implemented.  It  is  to  provide  the  user  with  the  ease  of  building 
the  data  structure  components  of  a  geometric/graph  object.  A  Class  Browser  showing 
the  GeoLIB  class  hierarchy  is  to  be  provided  with  the  component.  To  construct  a  data 
structure,  one  simply  draws  the  structure  diagram  and  specifies  each  component  as 
either  a  sub-structure  or  an  object  inherited  from  the  GeoLIB  class  hierarchy.  Once  the 
design  is  complete,  a  prototype  based  on  the  C  language  (or  C"'"'')  will  be  generated. 
There’s  no  need  to  implement  separate  display  routines  for  the  new  data  structure, 
since  they  can  all  be  inherited  or  composed  from  the  built-in  classes  in  GeoLIB. 

7.  GeoAnimator  -  An  animator  builder. 

GeoAnimator,  which  is  not  yet  implemented,  is  the  component  for  building  an  anima¬ 
tion  sequence  of  a  fully  debugged  program  in  the  GeoMAMOS  environment.  A  record 
button  will  be  supplied  in  each  watch  window  to  activate  the  recording  process  of  the 
current  display.  Each  update  to  the  display  canvas  is  saved  as  an  individual  frame  in 
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a  metafile.  And  each  frame  contains  only  the  most  recent  display  information  of  the 
object  (s)  currently  shown  in  the  window.  A  set  of  frames  can  be  concatenated  to  form 
a  series  of  films  and  later  on  edited  or  played  back  by  GeoAnimator. 

8.  GeoAnalyzer  -  A  profiler. 

Geo  Analyzer  is  not  yet  implemented.  It  is  to  provide  timing  analysis  tools  for  the 
user’s  program.  The  overall  running  time  of  the  program  can  be  recorded,  or  certain 
key  operations  can  be  tracked. 

In  addition  to  the  above  routines,  a  number  of  geometric  algorithms  have  been  imple¬ 
mented  with  built-in  visualization  routines  and  they  are  all  put  together  under  a  common 
subdirectory.  This  will  be  used  as  an  initial  base  for  geometric  software  library.  More  soft¬ 
ware  packages  will  be  added  as  soon  as  they  are  implemented  and  tested.  Since  our  geometric 
software  makes  heavy  use  of  LEDA^  an  on-line  menu  of  its  functions,  which  can  be  found 
in  http://web.ece.nwu.edu/~theory/leda/  has  been  prepared  to  facilitate  the  implementa¬ 
tion  of  geometric  algorithms.  The  GeoMAMOS  environment  will  help  geometric  algorithm 
designers  to  develop/implement  new  codes  and  via  WWW  further  growth  and  distribution 
of  geometric  software  can  be  expected  as  well. 

While  most  geometric  algorithms  require  a  graphical  ouput  to  show  the  results,  it  is  a 
good  design  practice  to  separate  machine-dependent  output  modules  from  the  monitoring 
system.  In  doing  so  it  can  provide  a  consistent  graphic  output  without  requiring  the  user 
to  develop  a  user  interface  to  the  program.  The  main  execution  of  the  program  only  needs 
to  be  concerned  with  I/O  and  internal  data  manipulation,  while  the  display  routines  can 
be  executed  by  the  system  concurrently.  A  salient  feature  of  the  monitoring  system  is 
the  ability  to  visualize  the  contents  of  various  geometric  objects  dynamically.  Our  system 
deviates  from  the  traditional  ones  in  that  we  do  not  require  the  usage  of  metafiles  to  store 
the  intermediate  results  and  therefore  do  not  rely  on  a  data  visualizer  to  display  them. 
This  is  done  via  GeoIPC  that  sends  the  contents  of  the  objects  directly  to  the  visualization 
subsystem  via  messages. 

The  manipulation/monitoring  system  supports  C  as  well  as  C"'"'"  on  many  Unix  ma¬ 
chines  with  or  without  the  multi-thread  support.  Users’  programs  need  not  know  the  data 
exchanged  between  the  system  and  each  display  window,  as  the  monitoring  process  is  set 
to  run  independently  of  the  execution  of  the  program.  Consequently  the  program  itself  is 
fully  portable  as  C  and  are  portable  to  many  platforms.  The  monitoring  system  can 
also  be  used  to  test  if  a  certain  heuristic  or  approach  to  a  problem  has  promise  to  produce 
fruitful  results  or  not.  Providing  a  graphics  output  as  the  algorithm  executes  can  give  us 
insights  into  whether  a  particular  heuristic  may  or  may  not  work.  Allowing  user  interaction 
during  the  monitoring  process  proves  useful  for  heuristic  design  in  improving  its  performance 

^Naher,  S.,  “LEDA  -  A  Library  of  Efficient  Data  Types  and  Algorithms,”  Max-Planck-institut  fiir  infor- 
matik,  Saarbriicken,  Germany,  1992. 

^Naher,  S.  and  C.  Uhrig,  “The  LEDA  User  Manual,”  Version  R  3.2,  Tech.  Report,  MPI-I-95-1-002, 
Max-Planck-institut  fiir  informatik,  Saarbriicken,  Germany,  1995. 
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as  well.  GeoSheet  was  very  helpful  in  obtaining  the  result  of  minimal  Steiner  tree  in  the 
A-orientation  plane[20]. 

A  number  of  undergraduate  and  graduate  students  were  involved  in  the  GeoMAMOS 
project.  Several  graduate  students  obtained  M.S.  degree  and  one  obtained  a  Ph.  D.  degree. 
We  have  incorporated  GeoSheet  into  our  curriculum  and  introduced  undergraduate  and 
graduate  students  to  the  notion  of  geometric  computing  and  visualization. 
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